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ABSTRACT 


The  National  Bureau  of  Standards  Institute  for  Computer 
Sciences  and  Technology  (ICST)  has  prepared  specifications 
for  the  International  Organization  for  Standardization's 
(ISO)  Class  4 Transport  Protocol.  At  the  request  of  a number 
of  companies,  ICST  organized  a workshop  series  for  implementors 
of  these  specifications  using  local  area  networking  technology. 

The  first  workshop  focused  on  implementation  techniques  and 
strategies  so  that  a multivendor  demonstration  of  these 
protocols  can  occur  at  a major  computer  conference  in  1984 
targeted  for  the  NCC  1984.  Primarily  the  details  of  CSMA/CD 
and  Transport  Class  4 were  discussed  and  parameters  were 
selected.  A second  workshop  focused  on  token  bus  LANs  and 
file  transfer  applications  to  be  run  at  the  trageted  1984 
demonstration.  Agreements  on  the  specifics  of  the  file 
transfer  protocol  were  reached  at  the  third  workshop.  The 
fourth  workshop  covered  futher  refinements  to  the  file  transfer 
protocol,  testing  procedures,  and  demonstration  details. 

This  report  documents  the  fifth  workshop  in  the  series  of 
LAN/Transport  workshops.  The  fifth  workshop  defined  the 
File  Transfer  Protocol  (FTP)  testing  schedule  and  minimum 
vendors  tests,  and  made  minor  adjustments  to  the  FTP  specification. 

Keywords:  communication  protocols,  computer  networks,  transport  protocol, 

file  transfer  protocol,  local  area  networks. 


SUMMARY 


This  report  documents  the  fifth  workshop  of  the  LAN-Transport  Workshop 
series  for  implementors  of  the  ICST  specification  of  the  ISO  Class 
4 Transport  Protocol  over  IEEE  802  compatible  LANs. 

At  the  fifth  workshop  vendor  dependent  minimum  FTP  tests  were 
agreed  to  and  an  FTP  schedule  was  set.  All  vendors  agreed  to 
implement  the  FCOPY  utility  and  supply  disk  space  so  that 
they  can  participate  in  the  FTP  demonstrations.  Refinements  to  the 
file  transfer  protocol  were  approved  and  transport  protocol  testing 
experiences  were  covered.  It  was  announced  that  a news  worthy 
event  for  the  business  press  would  be  held  in  the  U.S.  and  ICL 
would  make  a press  release  in  Europe,  both  events  will  be  in  April. 
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2.  Opening  Remarks 

Dr.  John  Heafner  opened  the  meeting  and  acted  as  chairman  for  Mr.  Maris 
Graube  who  did  not  attend.  The  agenda  was  reviewed.  An  FTP  test  schedule 
and  status  report  of  transport  testing  was  added  and  FTP  problems  and  FTP 
differences  were  merged. 

3.  Sub-Group  Status  Reports 

3.1  Mr.  R.on  Yara  of  Intel  presented  the  CSMA/CD  status  report.  In  the 
CSMA/CD  meeting  of  March  7 (also  attended  by  GM),  both  the  vendor  for 
constructing  the  booth  and  the  style  of  the  booth  at  the  NCG  were  selected. 
The  style  of  the  brochure  was  also  selected;  fifty  thousand  copies  of  the 
brochure  will  be  printed.  NCR  is  coordinating  this  effort.  The  logo 

will  be  reviewed  by  NCR  and  CRDS  on  April  2. 

It  was  noted  that  the  common  cable  could  not  run  outside  of  the  booths. 

A vendor  could,  however,  act  as  a gateway  and  run  a separate  cable  if 
desired.  The  separate  cable  would  be  the  responsibility  of  the  vendor. 

3.2  Mr.  Ed  Deenihan  of  GM  presented  the  token  bus  status  report.  The 
vendor  testing  schedule,  shown  as  Attachment  A,  was  presented  as  a proposed 
schedule.  Vendors  must  test  with  NBS  before  testing  with  GM  (Telenet 
encouraged).  Confusion  as  to  the  number  of  required  NBS  test  scenarios 

was  clarified:  There  are  139  required  transport  protocol  test  scenarios 

and  several  optional  ones.  The  complete  list  is  given  in  Attachment  B. 

The  transport  CR  and  CC  were  reviewed  and  it  was  decided  to  allow  data  in 
these  PDUs.  Hence,  six  tests  were  added  to  the  139  test  set. 

DEC  will  supply  the  reference  FTP  and  IBM  the  reference  MSG  implementations. 

At  this  point  the  question  of  who  could  be  Included  in  the  press  release 
was  raised.  The  final  determination  was  only  those  participating  in  the 
booth. 

4.  FTP  Problems  and  Protocol  Refinements 

4.1  Ms.  Pat  Amaranth  representing  GM  spoke  on  three  topics:  GM  FTP 

agreements,  open  issues  and  DEC's  replies  to  FTP  implementations  issues. 

John  Heafner  stated  that  if  there  are  any  changes  to  the  existing  FTP 
specification,  a new  document  would  have  to  be  generated. 

4.1  GM  FTP  Agreements 

A copy  of  Attachment  C "Current  GM  FTP  Agreements"  was  made  available  to 
all  attendees.  These  are  agreements  to  make  the  FTP  implementations  on  all 
machines  easier.  The  following  points  were  brought  out  in  the  ensuing 
discussion: 

o Only  one  TSAP  id  for  FTP, 
o File  type  not  in  CC  Transport  PDU, 
o Only  two  file  types, 

o FTP  document  is  more  current  than  Proceedings  of  the  4th  LAN- 
Transport  Workshop, 
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o One  FPDU  is  one  TSDU  - clarification  of  document  not  a change, 
o Text  file  types  will  have  .TXT  in  filename, 

o Buffering  is  a local  issue  for  TSDU  interface  does  not  require  it 
DEC  is  buffering  but  should  have  enough  memory  to  avoid  problems. 

It  was  agreed  that  items  two  through  seven  of  Attachment  C,  would  be 
adhered  to  by  both  groups.  Logging  (item  number  eight)  was  left  as  an 
option  for  the  CSMA/CD  group. 

4.1. B  Open  Issues 

The  error  id,  error  code  and  diagnostic  fields  in  the  open,  close  and 
release  are  now  mandatory  and  in  the  order  presented.  Success  or  warning 
are  assumed  to  have  worked  properly.  The  diagnostic  field  may  have  a 
length  code  of  zero. 

The  question  of  data  in  the  T_DISC  was  debated.  It  was  decided  that 
transport  will  accept  data  in  the  T_DISC  (not  a protocol  violation)  but 
what  it  does  with  it  is  optional.  The  data,  however,  must  be  an  ASCII 
string. 

The  error  codes  defined  under  the  Error  Header  Item  (p.  35  of  FTP  Final 
Report)  overlap.  It  will,  therefore,  be  up  to  the  implementor  to  find 
out  what  each  means  as  debugging  progresses. 

It  was  agreed  that  the  receipt  of  an  F__CANCEL  Request  after  issuing  an 
F_CANCEL  Request  would  be  treated  as  a confirm  (just  as  transport  handles 
crossing  T. DISC's). 

The  transport  sequence  space  is  assumed  to  be  31  bits  but  may  be  negotiated 
to  seven  bits.  Participants  will  use  the  NBS  not  ISO  specification.  It 
has  been  agreed  that  31-bit  sequence  space  will  be  used  in  the  demonstration. 
Implementation  of  the  seven  bit  sequence  space  is  only  being  provided  for 
conformance  to  the  specification. 

4.1. C  DEC  Replies  to  FTP  Implementation  Issues 

All  issues  discussed  are  shown  in  Attachment  D.  There  is  a need  to 
solicit  questions  from  implementors,  find  answers  to  those  questions  and 
distribute  results.  Distribution  will  be  through  Jerry  Linn  of  NBS  (see 
section  11). 

5.  NAPLPS  Demo  and  Files 

Mr.  Kern  Hardman  of  BCS  described  the  NAPLPS  demo  (see  Attachment  E). 

BCS  will  use  the  HP  protocol  implementations.  The  demo  will  be  menu 
driven.  The  data  base  will  be  expanded  to  include  all  CSMA/CD  vendors. 
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The  database  will  be  filled  in  with  current  (e.g.,  what  is  playing  at  the 
hotels)  and  graphic  (e.g.,  naps)  information.  NAPLPS  files  will  be  retrieved 
from  the  system  on  which  they  are  stored  and  displayed  on  the  NAPLPS 
terminal.  Each  vendor's  logo  and  one  frame  of  company  information  can  be 
displayed.  The  company  information  frame  will  be  a statement  already 
done  by  each  vendor.  The  frame  is  limited  to  fifteen  rows  of  eighty 
characters  and  is  needed  by  April  2.  Company  information  frames  and 
logos  should  be  sent  to  Mr.  Kern  Hardman,  Boeing  Computer  Services,  P.0. 

Box  24346,  MS  7A-05,  Seattle,  WA  98124.  DEC,  Intel,  ICL,  and  Honeywell 
volunteered  to  house  the  BCS  and  NBS  frames. 

The  biggest  problem  envisioned  was  getting  the  data  files  on  the  appropriate 
hosts.  BCS  had  a problem  with  added  carriage  return  line  feeds  when  they 
moved  a NAPLPS  file  from  one  host  to  another.  This  should  be  cured  by 
FCOPY  (see  section  6). 

6.  FCOPY 

Mr.  Allen  Rochkind  of  Intel  presented  a solution  to  the  file  loading 
problem,  the  FCOPY  utility.  FCOPY,  which  would  use  FTP  in  read-mode, 
would  provide  the  needed  functionality  to  overcome  incompatible  media. 

It  would  work  like  the  following  (underlined  are  user  supplied); 

FCOPY 

FTP  File  Copy  Utility 
Remote  File  Owner  Name:  BCS 
FTP  File  Name:  XYZ.Bin.BCS 

Local  Pathname:  /awO/ ncc / xyzbb 

The  file  type  would  come  from  the  FTP  File  Name.  All  CSMA/CD  vendors 
agreed  to  implement  FCOPY. 

7.  HIS  Demo  and  Files 

Mr.  Bruce  Carlson  of  Honeywell  presented  a preliminary  proposed  application 
(see  Attachment  F).  The  trivia  quiz  (e.g.,  sports,  movies,  history) 
would  have  each  set  of  questions  and  answers  on  a different  host. 

The  problem  of  the  expanding  number  of  file  names  that  would  appear, 
mostly  unneeded,  in  a FILE. DIR  was  debated.  The  resolution  was  that 
FILE. DIR  would  supply  all  names  and  it  is  up  to  the  requestor  to  display 
them. 

ICL  will  implement  the  menu  described  at  the  Seattle  meeting. 

8.  FTP  Testing  and  Schedule 

8.1  DEC  FTP  Implementation  and  Tools 

Mr.  Keven  Miles  of  DEC  described  the  status  of  two  software  packages;  the 
FTP  reference  implementation  and  the  Test  PDU  Sender  (see  Attachment  G). 

The  FTP  implementation  comes  with  full  logging,  multiple  concurrent 
transfers  (multiple  copies)  and  no  write/create.  The  implementation  i 
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due  at  GM  on  April  9.  This  is  a conforming  implementation  and  does  not 
inject  errors. 

The  Test  PDU  Sender  can  generate  incorrect  or  out  of  order  FPDUs  with 
full  logging.  There  are  no  scenario  command  files  at  present.  DEC  will 
make  available  whatever  is  used  to  test  their  FTP.  Volunteers  were 
solicited  to  expand  this  set.  GM  will  coordinate  the  collection  of 
scenarios  and  generate  some.  Ken  Aird  of  HP  will  generate  some  scenarios 
(see  Attachment  H).  Gould  will  also  do  some  for  state  transitions 
including  write  create. 

8.2  FTP  Testing 

Ms.  Pa.t  Amaranth  described  the  GM  FTP  Testing  Agreement  (see  Attachment 
I).  The  GM  tape  will  be  in  TAR  format. 

A discussion  of  minimum  FTP  testing  was  resolved  by  vendors  agreeing  to 
meet  various  testing  requirements.  The  testing  requirements  were: 

1.  send,  receive  and  compare  one  file  (to  DEC  and  return), 

2.  send,  receive  and  compare  all  files  in  agreed  upon  set,  algorithms 
published  by  James  Berets  of  BBN,  "N"  lines, 

3.  send,  receive  and  compare  GM  file  set  "N"  times, 

4.  ten  concurrent  connections  of  type  3, 

5.  Test  PDU  Sender. 

The  vendors  agreed  to  do  the  following  tests: 

TYPE  VENDOR 


1 

Intel , 

Gould, 

ICL , 

NCR,  HP, 

DEC, 

HIS 

2 

Intel, 

Gould , 

ICL, 

NCR,  HP 

3 

Intel , 

Gould, 

ICL, 

NCR,  HP, 

DEC, 

HIS 

4 

Intel , 

Gould , 

ICL, 

HP,  DEC, 

HIS 

5 

Intel , 

Gould, 

ICL 

NCR,  HP, 

DEC, 

HIS 

An  FTP  test  schedule,  at  NBS,  was  agreed  to  as  follows: 


April  16-20 
May  7-11 
May  14-18 
May  21-25 
May  28-June  1 
June  4-8 
June  11-15 
June  18-22 


DEC 

HIS 

I CL , NCR 
Intel,  HP,  BCS 
ACC/CRDS 

Full  System  Tests 
Full  System  Tests 
Ship  Out 


When  testing  at  NBS,  vendors  will  be  given  a five  meter  cable  which  can 
then  be  connected  to  the  long  cable.  Multiplexing  of  testing  has  worked 
out  best. 
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9.  Common  Business 


The  press  day  scheduled  for  April  25  is  cancelled.  In  its  place  a news 
worthy  event  will  be  created  by  having  the  Secretary  of  Commerce,  Malcolm 
Baldrige,  the  Director  of  NBS,  Ernest  Ambler,  the  President  of  BCS,  Mr. 
Robert  Dryden  and  a Vice  President  of  General  Motors  sign  agreements  for 
the  NCC  demo.  I CL  will  issue  a press  release  in  Europe  like  the  original 
release  after  checking  with  NBS  and  after  signing.  Vendors  who  want  to 
make  minor  revisions  should  go  through  NBS  for  technical  review.  Mr. 
Robert  Blanc  is  the  contact  point. 

10.  Arbitration  of  Technical  Points 

NBS  was  selected  as  the  focal  point  to  arbitrate  technical  issues  and 
disseminate  answers.  Mr.  Jerry  Linn  is  the  contact  point  for  both 
Transport  and  FTP.  Telex  is  acceptable  (Telex  number  898493). 

11.  Transport  Testing  Experiences 

11.1  HP 

Mr.  Ken  Aird's  major  problems  were  porting  the  scenario  interpreter  and 
addressing  in  the  NISL.  HP  used  a 3COM  transceiver.  The  ICL  monitor  box 
was  useful  but  couldn't  be  used  for  master  scenarios  (run  all  scenarios). 
Mr.  Stephen  Nightingale  of  JIBS  was  specifically  commended  for  providing 
assistance. 

11.2  Gould 

Gould's  major  problem  was  getting  TELENT  link  service.  A line  monitor 
was  useful  to  see  that  invalid  PDU's  came  across  when  expected.  Mr. 

Jeff  Gura  of  NBS  was  cited  for  outstanding  service  and  being  available 
any  hours  needed. 

Other  vendors  have  completed  transport  testing  with  NBS,  but  did  not 
provide  comments  at  the  workshop. 
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ATTACHMENT  C 


CURRENT  GM  FTP  AGREEMENTS 
MARCH  7,  1984 


1. 


Maximum  file  size  will 


be  limited  to  8K  octets. 


File  content  is  limited  to  ASCII  text  characters 
Each  variable  length  line  of  text  is  terminated  by 
a CRLF  (ASCII  carriage  return/  line  feed  pair  ).  A 
single  line  of  text  is  2 to  82  octets  in  length  (0 
- 80  text  chars  + CRLF). 


A file  may  be  transmitted  as  one  or  more  FDATA 
requests. 


Each  FDATA  request  contains  an  arbitrary  partition 
of  the  complete  file  data  and  may  contain  multiple 
or  partial  text  lines. 


Each  FDATA  request  becomes  a single  t-DR  PDU  sent  a? 
a TDATA  request. 

Only  one  file  read  should  be  done  for  each  file 
connection. 

Filenames  for  FSELECT  PDUs  and  local  FILEDIRs  are 
in  the  format:  filetitle.  filet ype.  filecwner  (eg 

FABLE.  TXT.  MOT) 

Each  vendor  will  keep  an  FTP  LOG  of  connects  (CR 
and  CC)  and  disconnects  with  reason  code 
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ATTACHMENT  D 

DEC  Jt£F€ft£**C£  *EPLIES  TO  FTP  IMPLEMENTATION  QUESTIONS 


■Q.:  Mill  the  r##*f*nct  support  sort  than  m«  c Mcumat 

FTP  incoming  and/or  outgoing  connection? 

Yes*  but  nut  multiplexed  within  the  FTP  codo. 

Mill  the  rtfere net  bo  using  FTP  response  timers  in 
addition  to  ovont  timer*  provided  in  Transport? 

I#  wo  have  time  we  mmy  implement  timer*. 

0:  What  it  the  reference  behavior  if  a filename  other 

than  the  filename  specific*  in  thm  FflFl  ECT  it 
returned  in  the  FSELECT  confirm?  Xs  this  an  error 
resulting  in  an  FA0OPT,  does  it  result  in  an 
F DESELECT  and  retry,  or  i%  it  not  an  error  detected 
by  the  protocol  machine? 

The  reference  imp  lamentation  will  ignore  this  condition*  and  will  net  generate 
this  condition.  In  any  case.  I would  not  regard  this  as  an  error  since  the 
returned  name  may  the  the  full  filename,  e. g. . after  defaults  have  teen 
app lied. 

0:  Is  it  an  error  to  select  a file  that  dots  eiist  tut 

is  not  contained  in  the  local  FILEDIR?  < sae  clausa 
6.  t.  2 of  the  CM  agreements  document  for  description 
of  FILEDIR) 

The  reference  implementation  will  not  generate  an  error  for  this. 

<1:  re:  INTEL'S  "NOTE  ABOUT  IMPLEMENTING  MULT  I VENDOR 

FTP**.  January  3.  1904  Does  the  reference  intend  te 
send  DT  TPDU's  with  EOT?  Does  it  expect  to  receive 
only  DT  TPDU's  with  EOT?  If  not.  in  the  case  where 
an  FDR  PDU  is  sent  as  a series  of  DT  TPDU's.  will 
only  the  first  DT  TP DU  te  expected  to  have  an  FP DU 
header  or  will  all  of  the  DT  TPDU's  have  an  FP DU 
header  inserted  as  in  INTEL'S  description? 

• 

I havn't  seen  Intel's  document.  However,  segmentation  ef  TSOUt  is  a Transport 
Protecei  issue  end  is  NOT  e Trenspert  Service  issue.  The  Transport  Service 
provides  for  the  transfer  of  complete  TSDUs.  An  FDR  PDU  Is  a complete  TSDU. 

The  fact  that  a complete  TSDU  mau  be  transferred  as  a number  ef  separate  TPOUl 
should  not  normally  bo  reflected  at  the  Service  Interface.  Thus*  if  an  FPCU  is 
transferred  as  a number  of  DT  TP DU*.  the  responder  should  enlg  see  the  arrival 
of  the  concatenated  FPDU.  However,  this  depends  upon  the  Transport 
implementation  at  the  responder. 

<0:  Haw  many  times  will  the  reference  retrg 

establishing  a connection? 

The  Fil'd  Transfer  Protocol  does  not  include  retries.  - Thuds  It  wi  J 
The  Transport  Service  will  send  up  to  4 CRs  before  It  gives  up. 
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ATTACHMENT  F 


MULTI -VENDOR  DEMONSTRATION  FILE  TRANSFER  PROTOCOL 


TEST  PROTOCOL  DATA  UNIT  SENDER 


Digital  Equipment  Co*  Ltd. 

Acre  Road 

Reading 

England 


5 March  1954 


15 


rt  H 


FTP  Test  PDU  Sender 


1 . 0 INTRODUCTION 

The  Test  PDU  Sender  (TPS)  is  a program  that  sends  and  receives  FPDUs 
to  and  from  a remote  FTP  implementation.  An  Event  Logger  is  used  to 
og  all  Transport  events  and  data  received  and  transmitted.  For 
escing  purposes  TPS  can  be  instructed  to  send  many  types  of  invalid 
PDU , 


TPS  is  designed  to  emulate  a FTP  implementation 
the  FTP  implementation  being  tested.  The 
between  TPS  and  FTP  is  that  TPS  sends  and 
pre-det ermined  sequence  of  FPDUs  and  if  abort 
received  FPDUs  are  not  what  was  expected. 


, and  is  transparent  to 
significant  difference 
expects  to  receive  a 
s the  connection  if  the 
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2.0  GENERAL  DESCRIPTION 

TPS  is  a substitute  for  the  FTP  Responder  or  Initiator.  It  runs  on  a 
Digital  Equipment  Corporation  VAX  computer  system  under  the  VAX / VMS 
operating  system.  The  VAX  computer  is  connected  to  the  Local  .Area 
Network  (LAN)  via  appropriate  hardware. 


TPS  is  run  by  issuing  a DCL  (Digital  Command  Language)  command  to  the 
VAX  system.  When  running  as  the  FTP  Responder  the  command  is  issued 
by  a DCL  command  procedure  which  is  invoked  by  the  OSI  Transport 
implementation.  The  DCL  command  to  run  TPS  is  described  in  section 

2.1  of  this  document. 


TPS  operates  with  an  Event  and  Data  Logger  and  communicates  directly 
with  the  OSI  Transport  implementation  to  send  and  receive  FPDJJs. 
Commands  to  control  transmission  and  reception  of  FFDUs  are  stored  in 
a file  called  the  Scenario  Command  file.  The  commands  used  in  the 
Scenario  Command  File  are  described  in  section  2.2  of  this  document. 


The  Scenario  Command  File  is  accessed  either  by  a name  supplied  by  the 
command  to  run  TPS  or,  if  no  name  is  specified,  from  the  same  source 
as  the  command  was  issued  from. 

Transport  events  and  all  received  and  transmitted  FFDUs  are  logged  to 
a Logfile.  In  the  Logfile  FFDUs  are  formatted  into  the  fields  that 
they  contain  and  are  analyzed  for  some  types  of  error.  Had  FFDUs  are 
flagged  in  the  Logfile  and  their  contents  are  printed  in  hexadecimal 
for  further  analysis. 

The  Leaf ile  is  accessed  either  by  a name  supplied  with  the  command  to 
run  TPS  or,  if  no  name  was  specified,  it  is  written  to  the  terminal  or 
batch  log  for  the  job  that  issued  the  command. 


2 . i  DCL  Command  For  TPS 

Invokes  the  Test  PDU  Sender  (TPS) . 

TPS  runs  until  either  the  end  of  the  Scenario  Command  File  is 
encountered,  or,  when  executing  a scenario,  an  error  is  detected, 
a Transport  Connection  is  established  by  the  scenario  and  it  has  not 
been  disconnected  when  TPS  has  completed,  the  scenario  or  the  error  _ 
detected,  an  implicit  DISCONNECT  command  (see  section  1.2.2)  is  issued 
to  release  the  Transport  Connection. 


Format : 


TPS  Ct iie-soecJ 


C ommand  Qua i i f i e r s 

Det  ault s 

/L0GL"=f  ile- spec  3 

(see  t ext ) 

/ C NO  3 EXECUTE 

/ TT^'P'PTJT'jr 

/ UNO 3TIMEQUTE = value 3 

/T"rXEOrT=  1 5 

17 


FTP  Test  PDU  Sender 


Command  Parameters: 
f ile-spec 


Specifies  the  scenario  command  file  to  be  executed.  If  not 
specified  the  scenario  commands  are  read  from  SYS 5 INPUT : (by 
default  this  is  either  the  terminal  or  the  DCL  command  procedure 
that  issued  the  TPS  command).  If  the  file  specification  does  not 
contain  a file  type,  TPS  uses  a default  file  type  of  COM. 


Command  Qualifiers: 

/ LQGC  = f i le- speed 

Specifies  the  file  the  FTP  log  output  is  to  be  sent  to.  If  this 
qualifier  is  not  specified  the  log  output  is  written  to 
SYS30UTPUT:  (by  default  this  is  the  terminal  or  batch  log  of  the 

job  that  issued  the  TPS  command).  If  you  omit  the  file 
specification,  TPS  gives  the  log  file  the  same  file  name  as  the 
scenario  command  file  and  a file  type  of  LOG. 


/ EXECUTE 
/ H 0 EXE  C UTE 


Controls  whether  the  scenario  commands  are  executed  or  only  a 
syntax  check  of  the  scenario  commands  is  made.  By  default  the 
scenario  is  executed.  If  the  commands  are  being  executed  a bad 
command  will  terminate  the  scenario.  If  only  a syntax  check  is 
being  carried  out,  bad  commands  will  be  flagged  and  processing 
the  scenario  will  continue. 


/TIME OUT C =value3 
/MOT I ME OUT 


Specifies  a timeout  to  be  applied  to  all  network 
operations.  The  value  is  given  in  seconds, 
specified,  the  timeout  period  is  infinite.  The 
period  is  15  seconds.  The  /TIMEOUT  qualifier 
/ N 0 EXE C UTE  qualifier  is  specified. 


r e ad  ( receive) 
If  / MOT I MEO UT  i s 
default  timecut 
s ignored  if  the 


Examples : 

1 . $ TPS 


Execute  the  scenario  which  is 
the  command  is  issued  from, 
terminal  or  batch  log  of  the  job  that  issued  the  TP 
The  default  timeout  of  15  seconds  is  applied  to  a 
read  operations. 


read  from  the  same 
The  log  file  is  writ 


source  as 
ten  to  the 
3 command. 
11  network 
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5 TPS / NO EXECUTE  TESTI/LOG 

Performs  a syntax  check  of  the  scenario  file  TE3T1.COM, 
writing  the  locr  to  TEST1.LQG.  As  no  network,  read,  operations 
are  performed,  no  timeout  is  applied  to  anything. 

,s  TPS /TIME^kTT=  2 / LOG— FTPLOG . DAT  TEET1 

COM,  writinu  the  loo 
is  applied  to  network 


Execute  the  scenario  command  file  TEST1 . 
to  FTPLOG. DAT,  A timeout  of  2 seconds 
read  operations. 


TPS  Scenario  Commands 


The  Test  PEU 

Sender  uses 

a series 

of  scenario 

commands  to  control 

its 

operation . 

These  commands  are 

described 

in  this  section. 

The 

commands  are 

stored  in  a 

f i i 0 * 

Each  command 

consists  of 

keywords 

and  pa ram 

eter  values  which 

are 

separated  b; 

y one  or  more  spaces 

or  t ab s , C 

ommand s may  be  cor.ti 

nued 

over  multiple  lines  by  placing  a hyphen  as  the  last-  non-comment 
character  on  the  line  to  be  continued. 

An  exclamation  point  ( ! ) is  used  to  designate  a comment.  A comment 
extends  from  the  exclamation  point  to  the  end  of  the  line.  A comment 
cannot  be  continued  on  to  the  next  line.  Comments  nay  also  be  placed 
at  the  end  of  a line  after  a command  (or  part  of  a continued  command) . 


Command  names  and  keywords  may  be  abbreviated  to  the 
letters.  Also  some  keywords  may  be  left  out. 
descriptions  these  words  are  enclosed  by  brackets  (C3) 


f ewe  5 1 un i o u e 
n c omiTisinci 


Certain  parameter  values  are  specitied  as  CTUoted  strincrs. 


strings  may 
( " ) , but  the 


be  pud  ted  -with  either  apostrophes  ( ' ) or  cruosaci 
starting  and  ending  quotes  must  match.  A quoted 


may  not  be  continued  over  more  than  one  line  of  the  scenario 

file. 


marks 
s •:  r intr 


Scenario  command  files  may  contain  as 
between  c ommand  s for  f orma 1 1 ing 

characters  at  the  beginning  of  a line 


many  blank  lines  as  re 
purposes.  Also  anv  Form 
are  discarded. 


yr  a 
& czr 
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2.2.1  Connect  To  Remote  FTP 

Establishes  a transport  connection  to  a remote  FTP  implementation.  No 
FFDUs  are  transmitted. 

Format : 

CONNECT  remote-id  PDU  C3IZE3  max-pdu-sice 


remote- id 


Identification  of 
implementation  the 
to.  It  is  specified 
is  *TBS*. 


the  remote  FTP 
connection  is  to  be  made 
as  a string.  The  format 


PDU  C3IZE2  max-pdu-si 


e Specifies  the  maximum  length  of  an  FPDU  t 
transmitted  over  this  connection.  I 
specified  as  a decimal  number  greater  than 
The  default  value  is  256. 


10  . 
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2.2.2  Disconnect  From  Remote  FTP 

Disconnects  the  transport  connection  to  a remote  FTP  implement 
Mo  FPDUs  are  transmitted. 


Format : 
DISCONNECT 
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2*2.3  Send  FPDUs  To  The  Remote  FTP 

Euilds  a FFDU  and  transmits  it  to  the  remote  FTP*  If  data  is  to  he 
transmitted,  multiple  FFDUs  may  be  transmitted,  depending  on  the 
amount  of  data  to  be  sent,  and  the  maximum  PDU  size  set  up  with  the 
CONNECT  command. 

The  send  command  allows  any  header  fields  to  be  transmitted  in  any 
type  of  PDU.  This  facility  is  provided  in  order  that  invalid  PDUs  may 
be  transmitted.  The  header  fields  are  placed  in  the  header  in  the 
order  in  which  they  were  specified  in  the  command. 

If  data  is  transmitted  in  a PDU  and  the  data  type  id  is  specified  as 
ASCII  text;  the  data  consists  of  the  ASCII  code  sequence  from  "1" 
through  and  is  offset  one  character  into  the  sequence  after  every 
<CR>  <LF>  pair.  If  the  data  type  id  is  any  other,  the  data  consists  of 
octets  containing  the  values  0 through  255  decimal,  and  is  offset  one 
octet  into  the  sequence  in  every  consecutive  PDU.  Both  these 
sequences  are  repeated  if  the  end  of  the  sequence  is  reached. 


Format : 


SEND 


v H i 


i-type-id 


Pdu  — t Trp  0 — i h. 


SERVICE  C SUBSETS  3 e rvi ce— sub s e t — id 

F I LEN AME  filename 

ERROR  error- id 

ERROR  TYPE  error-type- id 

D I AGNO ST I C CSTRINGo" diaa-stri ng 

DATA  TYPE  data -type-id 

DATA,  data-octet -count  DATA.  LENGTH  data-length 


Defines  the  PDU- type  id  in  the  header  of  the 
PDU  to  be  transmitted.  It  is  specified  as  one 
of  the  following  strings  or  as  a decimal 
number  in  the  ranee  0 to  255. 


u’f'D 

file 

f’nnnpr*-  reqi  \ pct 

FCC 

file 

connect  confirm 

FRLR 

file 

release  request 

FRLC 

file 

release  confirm 

F3R 

file 

select  request 

FSC 

file 

select  confirm 

FDSR 

file 

deselect  request 

FD3C 

file 

deselect  confirm 

FOR 

* 

file 

open  request 

FOC 

file 

open  confirm 

FCLR 

f 

close  request 

FCLC 

file 

close  confirm 

FRR 

file 

read  reciuest 

FRC 

file 

read,  confirm 

FDR 

f i 2. 0 

data  request 

FDER 

file 

data  end  request 

FTER 

file 

transfer  end  request 
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SERVICE  C SUBSETS 
service- subset -id 

FILENAME  filename 


error  type 

error  — type  - id. 
ERROR  error  — id. 


DIAGNOSTIC  L STRINGS 
diag-string 

DATA  TYPE 
data-type- id 


DATA,  da  t a - o c t e t - c cunt 


DATA  LENGTH 
data-length 


FTEC 

file 

transfer  end  confirm 

FCANR 

file 

cancel  request 

FCANC 

f i 1 0 

cancel  confirm 

FHR 

file 

write  request 

FWC 

file 

write  c onf i r m 

FCRR 

flip 

rprjtjpqf 

FCRC 

file 

create  confirm 

Specifies  the  subset  service  id  in  the  service 


subset  header 

item. 

It  is  specified  as  a 

decimal  numbe 

r in  the  range  0 to  15. 

Specifies  the 

f i l ena 

me  string  in  the  filename 

header  item. 

It 

is  specified  as  a quoted 

string . 

Specifies  the 

error 

type  id  in  the  error  type 

header  item. 

It  is 

sp<=3'- if  i eb  ay  a d^^imal 

number  in  the 

range 

0 to  15. 

Specifies  t he 

error 

id  in  the  error  header 

item.  It  is 

specif 

led  as  a decimal  number  in 

the  ranae  0 t 

o 15 . 

Specifies  the  diagnostic  string  in  the 
diagnostic  string  header  item.  It 

specified  as  a quoted  string. 


Specif 

header 

number 

values 


ies  the  data  type  id  in 
item.  It  is  specified 
in  the  rancre  17b  to  191 
are  defined: 


he  data 

El  3 EL 

The  f 


type 
dec  im 
ilowi 


or 


176  ASCII  text 

131  binary  dara 

any  other  values  are  interpreted  as  specifying 
binary  data.  The  default  value  is  ASCII  text. 

Specifies  that  data  is  to  be  transferred  in 
this  PDU.  It  is  specified  as  a decimal  nun 
in  the  ranae  1 to  65535.  If  the  soecif 
number  of  octets  cannot  be  transferred  in  one 
PDU,  multiple  PDUs  are  transmitted.  The  da : a 
transmitted  is  yenerated  internally  and 
depends  on  the  data  type  beincr  transmitted. 

Specifies  the  lencrth  of  the  data  field  in  th-' 
individual  FPDUs  transmitted.  TPS  wi  1 . 
attempt  to  put  data-length  octets  of  _:ser  da -a 
into  each  FPDU.  Less  data  will  be  put  in  t: 
FPDU  if  either  the  maximum  FPDU  sice  tree.:  ; ; 

in  the  CONNECT  command  (see  section  I. I. . 
would  be  exceeded,  or  more  data  ■.  un  * * . 
specified  by  data— octet - count  ■; ; c • . ; _ ; 

transmitted.  if  the  data  type  for  r r.e  FrTU 
ASCII  text,  then  a <CR><LF  pair  • 
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at 

data 

5C0C 

eoua 


the  end  of  the  data  in  each  FPDU  after 
-length  octets  of  text  data.  It  is 


ified  as  a decimal  number  greater  than  or 
1 to  1 . 
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2.2.4  Receive  FPDUs  From  The  Remote  FTP 


Receives  the  next  FPDU  and  checxs  its  pdu— type- id t or  receive. 
FPDUs  until  the  nexr  FPDU  received  hss  e.  specie  ied  pdu— type  - id . 


y— P 


Format : 

RECEIVE  pdu -type-id-1 


UNTIL  pdu- type- id- 2 


edd- tvpe-id-1 


Defines  the  PDU— type  id  of  the  PDU  to 
received.  If  the  PDU  is  not  of  the  specif 
type  the  scenario  is  terminated  and 
implicit  DISCONNECT  is  performed.  It 
specified  as  one  of  the  f ollowir.cr  serines 
as  a decimal  number  in  the  ranee  0 to  25 


d.  CD 

y- 


UNT s D pdu  — t y p e — i d — 2 


no  r~ 


FCR 

file 

connect  reeuest 

per 

file 

connect  confirm 

FRLR 

f -?  1 ^ 

r CD  | pq  CP  V PD  n'  1 <=  r 

FRLC 

file 

y pa  1 co  pi  r'fint  ■?  v-  -m 

d — 

file 

5 0 i 0 C - C 0 CT  LI  0 S L 

T“*r*  r“» 

T r\ 

t -?  “I 

rr  Ci  1 a (-  4-  .-,7-'  f -i  ir 

FDSR 

f T T - 

Hpcal  art  roni’pcr 

file 

n a c p 1 ca  <—  t“  r*  n rvF  * 

FOR 

file 

open  reeuest 

FOC 

file 

o k? 0 n coni"  i m 

u'r'r  Zj 

f 2.  l 0 

c in^s  reeuest 

file 

c l o 5 p conf i rm 

P'P  Pt 

file 

read  reeuest 

FRC 

f i i 0 

ra^C  rnnf  2.  If  ITi 

FDR 

r -i 

data  reeuest 

FDER 

file 

data  end  reeuest 

FTER 

d — .L  td 

transfer  end  reeuest 

-~vxrr 

r -?  ~ cd 

transfer  ^nd.  '3  mx  i n ^ 

FCANR 

l i 1 0 

cancel  reeuest 

FCANC 

flip 

cancel  conf  ini?. 

fwr 

f Hd 

yr  Ice  reciue  - 1 

FRJC 

file 

wr i t e confirm 

FrRP 

C-;  i o 

v- csrjijca  - 

FCRC 

f 1 

y v m h t p !—  n ^ r v ^ 

:ifies  that  ? 

DUs  o 

f pdu- type- id- 1 are  ts  be 

■ived  until 

a ? 

htt  wi *■  h a UP'U  -yp<=  ■»  <■* 

■ t . • j Tj  0 — i £ — 2 i 

s r8C0  iir0d  * If  ri0 

i iv0ri  e rm  cd 

i ti  ins  n 

t ypp  th<=>  scenario 

tinated  and 

an 

implicit  DISCONNECT  i s 

performed.  It  is  speoioied  either 
or  a decimal  number  in  the  ranee 


hove  for  the  possible  PDU  — type  - 2 i— . 
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Example  Scenario  Command  File 


! FTP  Responder  Test  (TPS  runs  as  FTP  Initiator) 

! This  scenario  command  file  first  sets  up  a transport 
i connection,  then  selects,  opens  and  reads  the  file  TEST. 
! When  the  transfer  is  complete  the  file  is  closed  and 
■ deselected  and  finally  the  transport  connection  is 
1 disc  cnn e c t ed . 


CONNECT  TESTMODE  - 


PDU  SICE  284 


Establish  Transport  Connection  to 
TESTMODE  and  use  a 
maximum  PDU  sice  of  284  octets. 


SEND  FCR  SERVICE  I 

! File 
! sub 

Connect  Request  — 
sec  cede  is  1 (file 

RECEIVE  FCC 

! File 

Connect  Confirm 

SEND  F3R  - 

• P T 1 

q pa  1 prr  CnniiPt;)- 

FILENAME  "TEST" 

! f il 

enaroe  is  TEST 

RECEIVE  ESC 

! File 

Select  Confirm 

SEND  FCR 

i File 

Open  Request 

RECEIVE  FOC 

! File 

Open  Confirm 

SEND  FRR 

! File 

Read  Request 

RECEIVE  FRC 

1 File 

Read  Confirm 

RECEIVE  FDR  UNTIL  FDEP. 

1 p_gr  p 

ive  FDR  PDUs  uo  to 

a FDEP.  PDU  (File  Data 


301TV1C9 

transfer ) 


oinci  includi 
End  Request 


ng 

) . 


SEND  FTER  - 


File  Transfer  End  Request 


ERROR  TYPE  0 - 
ERR  CP.  0 - 
DIAG  STRING  " " 


Error  Type  = Q — Success 
Error  - 0 — Success 
Null  Diagnostic  String 


RECEIVE  FTEC 
SEND  FCLR 
q'ESEIT7E  C 

SEND  FDSR 
RECEIVE  FDSC 
SEND  FRLR 
RECEIVE  FRLC 
DISCONNECT 


File  Transier  End  Confirm 
File  Close  Reciuest 
File  Close  Confirm 
File  Deselect  Request 
File  Deselect  Confirm 
File  Release  Request 
File  Release  Confirm 
Release  Transport  Connection 


i 


End 


example  scenario 


t End  f descript  ion  J 
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(Ju^  o-'f  * 

Sad.  p>*.r«,.*i*fe* 

VSy1~£j  vTei/^Seci 

W 3.  1-eJ^r^ 
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FTP  TESTING 

GM  vendors  have  agreed  to  the  testing  outline  prepared 
by  Jim  Berets  of  BBN  and  distributed  as  Annex  D of  the 
MULTI  VENDOR  DEMONSTRATION  FILE  TRANSFER  PROTOCOL  FINAL 
REPORT  REVISED*  December  1933*  with  the  following 
modifications: 

1.  Section  i - Tests  of  Normal  Operation 

Test  1 - "Transfer  file  between  like  machines" 
offsite  before  coming  on-site  at  GM. 

2.  Test  2 - "Transfer  file  between  different  machines" 
Steps  3 and  4 "Comparison"  will  be  accomplished  in 
the  following  manner. 

— GM  will  distribute  test  file  tape 

- vendor  — > ref  test*  DEC  reference  will 

request  the  test  file  suite  and  compare  against 
its  copy  of  the  test  masters. 

- ref  — > vendor  testj  DEC  reference  will 

transmit  the  test  file  suite.  Testing  vendor 
will  compare  against  its  local  copy  of  the  test 
masters. 

- Above  tests  will  be  repeated  for  a specified 
number  of  trials. 


3.  Section  3 - Tests  of  Robustness  will  be 

accomplished  with  the  err  or  — in j ec t ing  facilities 
provided  by  the  DEC  reference  implementation. 

4.  A multi-vendor  "Pull  loading"  test  period  will  be 
added  to  simulate  NCC  conditions. 
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